Firefox/Features/Expose Add-on Performance
Status
Expose add-on impact information at AMO and in Firefox | |
Stage | Definition |
Status | In progress |
Release target | ` |
Health | OK |
Status note | ` |
Team
Product manager | Justin Scott & Asa Dotzler |
Directly Responsible Individual | Justin Scott |
Lead engineer | Hernan Rodriguez Colmeiro, Dave Dash, Justin Dolske |
Security lead | ` |
Privacy lead | Sid Stamm |
Localization lead | ` |
Accessibility lead | ` |
QA lead | Henrik Skupin |
UX lead | Jennifer Boriss |
Product marketing lead | ` |
Operations lead | ` |
Additional members | ` |
Open issues/risks
`
Stage 1: Definition
1. Feature overview
Users should be informed when an add-on they are about to install or have installed causes Firefox performance and or memory problems. This information should be presented at AMO and in the Firefox Add-ons Manager.
2. Users & use cases
We should develop a new Add-ons policy, and acompanying AMO and Firefox technology, which says that we will inform our add-on users and prospective add-on users about specific add-ons that can be proved to have a significant and excessive impact on memory usage and/or performance. I propose we test for start-up performance impact, page load performance impact, start-up memory use impact, and memory leaks.
The policy should specify that we will notify the authors of add-ons as soon as we discover a problem and it should have a grace period for correcting any excessive memory or performance impact. I propose, as a straw-man, half a release cycle or 3 weeks from notification.
If after the grace period the add-on is not brought within compliance, we should add it to a list of ill-behaving add-ons. That list would be consumed by both AMO and the Firefox client. Both apps would use the list to display warnings to users about the impact of the add-on.
If after an additional 3 weeks of the add-on being flagged publicly, (again, a straw man) it is not corrected, we should escalate the content of and the and visibility of the warning message.
At AMO, I believe these poorly-performing add-ons should be flagged at the add-on install page. The warning should be firm but friendly -- something like "Mozilla testing has determined that this add-on may cause Firefox performance problems". If, after some period if time from the public warning the add-on is not corrected, the message should be escalated to display in search results and with a text that would more seriously deter users, something like "This add-on is known to cause serious Firefox issues. Use at your own Risk".
In the Firefox client, the flagged add-ons should display warning text in the Add-ons Manager (where informed users, or users following the instructions of a support article or other help, would see it,) and for the escalation period, to an infobar.
This would give add-on authors 3 weeks to fix problems before potential users and some of the installed base are notified, and another 3 weeks before most potential and all existing users would see the more dire warning.
3. Dependencies
Add-on testing capabilities, manual or automated.
An AMO API for "warned add-ons" and for "doubly warned add-ons"
AMO and Firefox code to access this API, get the lists, and display UI based on the lists.
4. Requirements
`
Non-goals
`
Stage 2: Design
5. Functional specification
`
6. User experience design
- Early design mockup: shows percentage of runtime used for each addon.
- [1]: newer mockup of the first stage
Stage 3: Planning
7. Implementation plan
`
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
-
File AMO bug to expose performance information in the API - File AMO bug to make use of the new fields and display warnings when appropriate.
-
File Firefox Add-ons Manager bug to make use of the new fields and display warnings when appropriate. - Obtain designs for the Add-ons Manager
- Implement the designs in the Add-ons Manager.
- bug 597282
- bug 621607
- bug 534020
- bug 659794 Dependency - Expose performance information in the API
Stage 5: Release
10. Landing criteria
`
Feature details
Priority | P3 |
Rank | 999 |
Theme / Goal | ` |
Roadmap | Add-ons |
Secondary roadmap | ` |
Feature list | Desktop |
Project | ` |
Engineering team | Desktop front-end |
Team status notes
status | notes | |
Products | ` | For more information, please see [2] [3] [4] |
Engineering | ` | ` |
Security | sec-review-complete | complete: 10.05 Notes |
Privacy | ` | ` |
Localization | ` | ` |
Accessibility | ` | ` |
Quality assurance | waiting | ` |
User experience | ` | ` |
Product marketing | ` | ` |
Operations | ` | ` |